OMU トラブルシューターの初仕事
概要
あなたの友人の A さんは、図1に示すネットワークを構築しました。このネットワークは以下のような設定がなされています。
- 各ルータ間はスタティックルーティングを行っている
pc
からsrv01
とsrv02
にアクセスできるsrv01
とsrv02
間はアクセスできない
図1
次に、rt01
と rt03
を直接接続することで、 pc
から srv02
へのアクセスのレイテンシを改善できるのではないかと考えました。ネットワーク構成を図2のように変更しようとしています。
- 各ルータが OSPF で接続されている
図2
しかし、設定を間違えてしまい、pc
から各サーバへアクセスできなくなってしまいました。
あなたは A さんに代わって、ダイナミックルーティングを使用したネットワークに変更してください。
また、A さんは以下のメモを残しています。
- ダイナミックルーティングに移行するにあたって、いくつかスタティックルーティングの設定を削除した。
- srv01 と srv02 の通信を拒否するために、rt03 に ufw というコマンドでファイアウォールを設定した覚えがある。
前提条件
- スタティックルートの経路は追加しないこと
- 全てのホストに割り当てられた IP アドレスを変更してはいけない
- 接続可能なホストには、
192.168.1.0/24
の接続用アドレスが割り当てられている srv01
にファイアウォールを設定してはいけない
初期状態
pc
からsrv01
およびsrv02
へアクセスできない
終了状態
pc
からsrv01
およびsrv02
へアクセスできるpc
からsrv02
への経路は、pc -> rt01 -> rt03 -> srv02
となるsrv01
からsrv02
へはアクセスできない- ダイナミックルーティングを用いた経路交換がなされている
補足
ルータの設定
rt01
, rt02
, rt03
では、FRRouting を用いて OSPF が動いています。次のコマンドで FRR の設定を行うことができます。
sudo vtysh
コマンド例
# 現在の設定を表示する
show running-config
# vtysh を終了する
exit
解説
この問題は、OSPFの設定を行ったにも関わらず、期待どおりに経路交換が行われない、というものです。
この問題では3つの設定ミスが複合して発生しています。
rt01
に不必要なスタティックルートの設定があるrt01
,rt02
の OSPF の設定において、router-id が重複しているrt03
に誤ったファイアウォールの設定がある
このため、これら3つ全てを解決することで、終了状態を満たすことができます。
想定していた解法
1.
rt01
と rt02
の間で router-id が重複しないように設定する必要があります。
ここでは rt02
の router-id を 2.2.2.2
に変更します。
sudo vtysh
rt02# configure
rt02(config)# router ospf
rt02(config-router)# ospf router-id 2.2.2.2
For this router-id change to take effect, use "clear ip ospf process" command
rt01(config-router)# end
なお、この後設定を適用するためには、vtysh内での clear ip ospf process
, clear ip ospf neighbor <neighbor>
といったコマンドの実行や、 sudo systemctl restart frr
など、何らかの形でOSPFのプロセスやネイバーを再起動/再接続する必要があります。
2.
rt01
の FRRouting のコンフィグを確認すると、次のスタティックルートの経路を確認できます。
ip route 172.16.40.0/26 172.16.0.2
恐らく、A さんの以前の設定が残っているのでしょう。
この設定により、pc
から srv02
までの経路がpc -> rt01 -> rt02 -> rt03 -> srv02
となっています。
次のようにコマンドを実行することでトラブルとなっている経路を削除できます。
rt02# configure
rt02(config)# no ip route 172.16.40.0/26 172.16.0.2
3.
rt03
のufwのstatusを確認すると、次の設定を確認できます。
user@rt03:~$ sudo ufw status numbered
Status: active
-- ------ ----
[ 1] 22 ALLOW IN 192.168.0.0/16
[ 2] 80 ALLOW IN 172.16.0.0/24
恐らく、A さんの以前の設定が残っているのでしょう。
この設定により、OSPFのパケットの交換が行えなくなっています。
次のようにコマンドを実行することで、OSPFのパケットを受信することが可能となります。
sudo ufw del 2
sudo ufw route deny from 172.16.30.0/27 to 172.16.40.0/26
sudo ufw default allow
sudo ufw reload
なお、他にも /etc/ufw/before.rules
でプロトコル番号89の通信を許可する、自身のアドレスとマルチキャストアドレス宛のパケットを許可するなどでもOSPFのパケット交換を可能とすることができます。
採点基準
pc
からsrv01
へアクセスできる- +30%
pc
からsrv02
へアクセスできる- +20%
pc
からsrv02
へアクセスでき、srv01
からsrv02
へアクセスできない- +20%
pc
からsrv02
への経路は、pc -> rt01 -> rt03 -> srv02
となる- +20%
- 完答ボーナス
- +10%
- スタティックルートの経路を追加
- -100%
- 全てのホストに割り当てられた IP アドレスを変更してはいけない
- -100%
講評
この問題は3つの原因が複合して発生したものであり、3つ全てを解決しないと満点解答とならない問題でした。
更に、OSPFとファイアウォールの組み合わせということもあり、ある程度難しい問題と考えて出題しました。
この問題で満点解答を提出したチームは6チームあり、大凡想定通りの難易度となったかなと感じています。
このトラブルの3つの原因の中ではスタティックルートの修正が最も簡単なものかとは思いますが、この箇所について気づいていない解答が多かったように感じます。
また、 rt03
におけるufwの設定にて、マルチキャストアドレス宛パケットの受信のみを許可し、ユニキャストでのパケット受信は拒否したままの解答が存在しました。
こちらについては、終了状態を満たし正常に通信が可能であること、採点基準において減点対象とならないことから、満点としました。
しかし、通信状態として必ずしも適正であるとはいえないため、実際に設定する際はユニキャストアドレスでの受信を許可するルールも必要となります。